20 Common Questions 20 Common Questions
Using a question-and-answer approach, this section explains what a communication server is; why we believe our servers provide the best features in the industry; and how you can determine whether a server is the right solution for your application.
What is a communication server?
A standard communication server brings wide-area connectivity to your local-area network. A typical server has at least one Ethernet connection, and any number of serial ports for wide-area connections. The serial ports can be configured with various electrical line interfaces, such as RS-232, RS-449 and V.35. Protocol software is installed in the server to provide communications over the Ethernet and the serial ports.
How is a communication server different from a router?
A router examines packets of data on the local-area network and, when the packets are addressed to a remote network, forwards them through a wide-area connection. At the remote site, another router typically reads the packets from the wide-area connection and transfers them to the local-area network. This all happens transparently to the applications exchanging data. In contrast, a communication server is designed to be accessed directly form application programs, allowing them complete control over the data that is transmitted and received on the serial lines.
Why should I use a communication server instead of installing a communication controller in my host backplane?
Sometimes an embedded communication controller can be a more cost-effective solution, but the server has a number of benefits. Its services can be shared equally by all the clients on the LAN. Serial ports can be added through expansion or additional servers. (The number of slots in your host's backplane is clearly limited.) Most important, if you have an assortment of client systems, or want to upgrade later, there's no issue of compatibility. With the server all each system needs is the UconX Application Programming Interface (API). An embedded controller requires porting a host device driver, which is very specific to your vendor's O/S (even if it's "standard" UNIX).
What industries typically use communication servers?
The process control (SCADA) industry uses communication servers to monitor and control operations at remote sites, such as power sub-stations, where there may be no human attendant. Brokerage firms use communication servers to tap into financial market data feeds (tickers) from trader workstations. All the workstations on the local-area network can share the information from the market feed. The government and military use communication servers to receive radar data, and to communicate with aircraft, satellites and probes.
How are the UconX servers different from others?
UconX servers run xSTRa, a STREAMS-based, real-time executive. standard STREAMS was designed as a software environment for communication protocols on UNIX systems. It allows protocols to be implemented in a modular fashion so they can be built and configured dynamically. Multiple protocols can easily run side-by-side in the same system, and many different applications can access them.
Are there other advantages of using a STREAMS-based communication server?
Because STREAMS is an industry standard, and xSTRa is completely STREAMS-compatible, you know that UconX's protocols are implemented according to recognized design guidelines. Protocols designed to run under UNIX STREAMS can be easily ported to our servers, and our protocols can be easily ported to UNIX systems.
Do UconX servers support network management?
Our communication servers support Simple Network Management Protocol (SNMP), the industry standard for network management.
How many protocols can run on a communication server?
With UconX servers, a different protocol can run on each serial port. Protocols are assigned to serial ports dynamically at run-time. This can provide a significant cost-saving over other communication servers that require a block of eight or sixteen ports to be assigned to a single protocol.
What protocols do you support?
UconX offers a wide array of standard, standard off-the-shelf communication protocols. These include X.25, HDLC Frame Transfer, HDLC ABM, HDLC NRM, ADCCP, DDCMP, Frame Relay, Radar Receivers, Synchronous Bit Stream Interface and Asynchronous Data Transfer.
What if I need a custom protocol?
Our software engineers are always available to assist you with any unique communication protocol requirements. Because of our expertise in this area and our library of existing protocol modules, we can typically develop standard custom protocols more cost-effectively than our customers can themselves.
Can I write my own protocol software for the server?
If you prefer to develop your own communication protocols for one of our servers, our standard ProtoKit software development package provides everything you need. ProtoKit allows you to use xSTRa to develop protocol modules in the STREAMS environment. We provide sample programs, serial device drivers, cross-development tools, a source-level debugger, complete documentation, and even a three-day training course at our facility.
How difficult is it to set up and configure the server?
Installation is easy. You can do it even if you know almost nothing about networking. You do need to choose an internet address for the server that's appropriate for your network, and you need to know the internet address of your client system. After that, it's just a matter of following a few simple instructions in our installation guide.
How does my application program access the server?
Your application program runs on a client system connected to the local-area network. Using the UconX standard API, your program establishes a network connection to the communication server and requests access to a particular protocol. Once the connection is open, your program can begin sending and receiving data and control information in a format defined by the protocol in use.
What is the purpose of the API?
The API provides your application with a standard STREAMS interface, shielding it from the actual TCP/IP interface used to communicate with the server. Your application makes simple subroutine calls, such as MPSopen to open a connection, MPSputmsg to send a packet of data, or MPSgetmsg to receive data. with the API, we can provide an application interface that is familiar to many programmers (because it's STREAMS), and is consistent across all UconX protocols, servers and embedded controllers, and supported client systems.
Even with the API, wouldn't my application be easier to write if I used an embedded communication controller?
No, not at all. Our protocols are supported on both servers and embedded controllers, and we use the same client applications in either case. The API takes care of all the differences between the two environments except one. For an embedded controller, the application must specify the UconX device name when opening a connection. For a server, the application specifies the server's network name and a TCP/IP service name instead. From then on, all operations are absolutely identical.
What types of client systems can use the server?
All an application program needs to access our servers is the UconX API, which is written in C and provided in source form. We provide a version for UNIX, which uses a standard socket interface to TCP/IP; and a version for VMS, which supports UCX, Process Software and Multinet TCP/IP packages. If you have another type of client system that supports TCP/IP, and you have a C compiler, you should be able to port our API with minimal effort.
Can the server be accessed from more than one client system?
Absolutely. That's one of the main advantages of a communication server. A single server can be accessed form multiple application programs on one client system or from applications running on many clients of different types. The client applications may be accessing a single protocol on the server or an assortment of protocols. The only restriction is that many protocols allow only one application connection for each serial port. Others, such as X.25 (which supports "virtual circuits"), allow multiple connections on a single serial port.
How many serial ports can a server support?
UconX communication servers can be configured with anywhere from two to 128 serial ports, with an assortment of electrical interfaces. Whether that many ports can be efficiently managed through a single Ethernet connection depends on serial line speeds and data throughput requirements. Since our servers are based on a scalable and extensible architecture, we can customize a cost-effective solution that gives you the performance you need.
What serial line speeds can a server support?
UconX servers support line speeds from 300 bps to T1/E1, or even higher in some cases. Line-speed requirements are one of the factors we consider when configuring a server.
Does my network have enough bandwidth to support the extra traffic generated by the server?
Ethernet supports a total bandwidth of 10M bps. Whether the addition of a communication server will impact your network depends on a number of factors, including serial line speed and the total number of serial lines. For example, if your server is configured for eight lines, full duplex, at 64K bps each, you will be adding a maximum of 1M bps to your network load. This is only ten percent of the Ethernet's total, and assumes constant traffic (full line utilization) in both directions on all eight serial lines. With most protocols, actual traffic is much lighter than this.
Ordering Information: For more information or to place an order, please contact us at (619) 627-1700 or email us at sales@uconx.com . For technical questions about our products, please email us at tech@uconx.com .